TiDB|TiDB在5A级物流企业核心系统的应用与实践

历经了近半年的测试验证和迁移准备&＃xff0c;神州金库3.0核心系统 WMS 正式从 MySQL 迁移到了分布式 HTAP 数据库 TiDB&＃xff0c;上线后不久就经历了第一次双11的考验&＃xff0c;TiDB 的性能和稳定性表现远超预期&＃xff0c;给后续的全平台迁移计划打下了坚实的基础。

神州数码 TiDB 交付团队与科捷物流技术、业务团队紧密配合&＃xff0c;完全自主化地实施了整个迁移过程&＃xff0c;成为团队在又一新行业成功交付的典型案例。

下面我们就来具体看看吧~

科捷物流概况

北京科捷物流有限公司于2003年在北京正式成立&＃xff0c;是ISO质量管理体系认证企业、国家AAAAA级物流企业、海关AEO高级认证企业&＃xff0c;注册资金1亿元&＃xff0c;是中国领先的大数据科技公司——神州控股的全资子公司。

科捷物流融合B2B和B2C的客户需求&＃xff0c;基于遍布全国的物流网络与自主知识产权的物流管理系统&＃xff0c;为客户提供定制化的一站式供应链服务&＃xff0c;在全国拥有231个仓储中心&＃xff0c;总面积超100万平方米&＃xff0c;年运送货值超5000亿元&＃xff0c;日发送包裹超40万个&＃xff0c;并在IT、通讯、精密仪器、汽车配件及电商物流领域处于行业领先地位。

神州金库简介

神州金库&＃xff08;KINGKOO&＃xff09;是科捷物流结合二十年物流运营经验自主研发&＃xff0c;支持云服务模式、实时数据接口的专业物流管理平台&＃xff0c;包含有四大核心子系统&＃xff1a;

订单管理系统&＃xff08;OMS&＃xff09;

仓储管理系统&＃xff08;WMS&＃xff09;

运输管理系统&＃xff08;TMS&＃xff09;

物流核算系统&＃xff08;BMS&＃xff09;

神州金库实现了物流业务体系的数字化全覆盖&＃xff0c;为客户提供了一体化的供应链系统解决方案。

神州金库平台经过十几年的更新迭代&＃xff0c;支撑了科捷物流自营仓储体系、众多电商平台商家、第三方物流公司的核心业务&＃xff0c;积累了庞大的数据量。

为应对持续增长的业务规模&＃xff0c;以及每年多次的电商大促活动&＃xff0c;急需寻找更加高效高性能的数据存储方案。

神州金库现有技术体系

神州金库服务端采用微服务架构体系设计&＃xff0c;不同的业务模块采用独立的集群部署模式。技术栈基于Java Spring框架构建。数据库目前主要使用 MySQL 主从集群&＃xff0c;多台高性能物理机部署&＃xff0c;通过 MyCat 做代理层进行读写请求转发。前端接入了多种不同的客户端形态&＃xff0c;包括Web、APP、IoT设备、扫描枪、计重器、机器人、报表、第三方API等等。

业务挑战

1、数据量激增带来一系列影响

随着数据量的持续快速增长&＃xff0c;MySQL 的存储容量即将达到上限&＃xff0c;SQL 响应时间开始变慢&＃xff0c;业务受到影响。

如果维持现有的技术架构&＃xff0c;下一步势必要引入分表机制&＃xff0c;同时扩展容量更大的集群&＃xff0c;这其中数据迁移就是非常大的工程量&＃xff0c;应用端还要引入额外的 sharding 中间件进行改造&＃xff0c;后续数据库维护成本和难度成倍上升。

2、数据报表和分析需求凸显

其次&＃xff0c;大量的数据报表和分析需求凸显&＃xff0c;仅仅依靠 MySQL 从库提供分析查询能力&＃xff0c;效率已经达不到业务需求。某些场景下汇总数据的时效性要求非常高&＃xff0c;直接影响到下一步的业务决策&＃xff0c;引入传统的T&＃43;1离线分析方案无法满足。

3、高并发挑战

除此之外&＃xff0c;在应对电商大促场景下需要数据库提供足够的并发能力&＃xff0c;响应比平时多出几十倍的流量高峰&＃xff0c;同时数据库还可以保证稳定的性能。在平时业务量较小的时候&＃xff0c;需要缩减配置控制成本&＃xff0c;达到弹性易于扩展的目的。

应对方案

基于以上需求&＃xff0c;技术团队决定引入分布式数据库代替 MySQL 单机数据库。

在充分考虑了应用和数据双方面迁移难度&＃xff0c;以及一系列 POC 验证后&＃xff0c;选择使用 TiDB 来替换 MySQL&＃xff0c;并用神州金库的核心子系统 WMS 作为首期试点项目。

选择使用 TiDB 的主要因素有&＃xff1a;

语法层面高度兼容 MySQL&＃xff0c;应用端代码中没有使用 TiDB 不支持的特性&＃xff0c; 最小程度减少应用改造成本&＃xff0c;更换数据库连接串即可。

存储计算分离架构能够满足弹性扩展需求&＃xff0c;针对不同时期的业务量动态调整节点达到所需的性能和容量&＃xff0c;还可以把不同业务单元的 MySQL 库合并到一个 TiDB 集群中&＃xff0c;自带高可用特性省去了 MySQL 从库的硬件成本&＃xff0c;数据库维护起来简单高效。

一站式 HTAP 体验&＃xff0c;同时满足交易型和分析性业务场景&＃xff0c;且对应用端透明。

开源产品&＃xff0c;技术社区活跃&＃xff0c;产品迭代快&＃xff0c;碰到问题容易解决。

测试

为赶在双11之前完成迁移任务&＃xff0c;我们做前期做了充足的测试工作&＃xff0c;包括应用兼容性测试和改造、多轮带实际业务的压力测试、模拟未来数十倍数据量的性能测试、稳定性测试、高可用测试、生产迁移演练等。

在压测中选取了仓储业务中最核心的出库流程&＃xff0c;一共包含6个场景&＃xff0c;分别是创建出库单、调度、创建波次、单据复核、单据交接、交接确认。

其中稳定性测试过程中除了使用传统的长时间高压业务负载&＃xff0c;还引入了 Chaos Mesh 混沌测试&＃xff0c;对CPU、内存、网络等发生异常情况进行模拟&＃xff0c;观察 TiDB 在测试期间的表现。从监控显示&＃xff0c;压测期间资源使用率和数据库响应时间都非常稳定。

迁移

生产环境TiDB集群部署架构和数据迁移流程如下图所示&＃xff1a;

在 TiDB 集群部署完成后&＃xff0c;使用官方提供的数据迁移工具 TiDB Data Migration&＃xff08;DM&＃xff09;开始把全量和增量数据同步到 TiDB 中。

然后找一个业务低峰期切断应用端到 MySQL 的流量&＃xff0c;待 DM 把数据追平后使用校验工具 Sync-Diff 对上下游数据做一致性检查&＃xff0c;校验完成开启 TiDB 到 MySQL 的回退链路&＃xff0c;防止切换出现故障可以随时回滚到 MySQL。

验证 TiDB Binlog 同步正常以后把应用端数据库连接切换到 TiDB 代理层的VIP&＃xff0c;通过 HAProxy 转发请求到 TiDB 计算层。

收益

迁移之后经过一个月的观察和调整&＃xff0c;各方面的性能指标都很稳定&＃xff0c;P99 延时基本在100ms以下&＃xff0c;服务器资源使用率普遍较低&＃xff0c;各节点压力均衡。

10月31日晚上9点左右&＃xff0c;迎来了双11的第一轮业务高峰期&＃xff0c;一直持续到11月3日&＃xff0c;在这期间 P99 延时没有明显波动&＃xff0c;但是集群 QPS 较平时上涨了5-8倍&＃xff0c;最高峰值达到1万多。

在11月1日和11月11日两轮业务高峰期&＃xff0c;TiDB 均表现得非常稳定&＃xff0c;没有发生任何故障和性能问题。本次迁移的 WMS 3.0在双11期间的流量约占整个金库系统的10%&＃xff0c;基于目前 TiDB 的优秀表现&＃xff0c;我们有充足的信心把所有业务系统逐步迁移到 TiDB。

短期来看&＃xff0c;TiDB 可能需要投入较高的硬件成本&＃xff0c;但是随着数据规模增长&＃xff0c;TiDB 的性价比会大幅提升。

首先 TiDB 的数据压缩比非常高&＃xff0c;三副本所需要的存储空间远低于三台 MySQL 主从节点&＃xff0c;这意味着三台 TiKV 可以存储比 MySQL更多的数据。

其次&＃xff0c;要提高数据库整体并发能力只需要增加 TiDB Server 节点&＃xff0c; 要扩展数据库容量只需要增加 TiKV 节点&＃xff0c;从运维成本和硬件成本都要低于 MySQL。

问题

1、SQL 行为一致性问题

从单机数据库到分布式数据库&＃xff0c;除了语法层面的兼容性之外&＃xff0c;我们还需要关注相同的 SQL 表现行为是否一致。

例如在早期的测试中发现&＃xff0c;当不显式指定排序字段时&＃xff0c;MySQL 查询结果能得到固定的顺序&＃xff0c;但是在 TiDB 中就会出现结果集顺序不稳定的情况。

这主要是分布式特性带来的表现差异。TiDB 会把扫描数据的请求并行下发给多个 TiKV 节点&＃xff0c;如果没有强制使用排序字段&＃xff0c;受 TiKV 返回数据时间不一致的影响&＃xff0c;最终的汇总结果必然没办法保证顺序&＃xff0c;这就要求业务开发过程中要保持良好的 SQL 编写规范。

2、热点问题

再就是使用 TiDB 普遍会遇到的热点问题&＃xff0c;上线初期由于某张表的索引建立不当&＃xff0c;导致某个索引读热点问题非常严重&＃xff0c;高峰期能达到100多G/min的流量。

我们从三个方向进行了优化&＃xff1a;

首先找到热点所在的 Region 尝试做切分&＃xff0c;会有短暂的效果&＃xff0c;但是受 Region 调度影响读热点依旧存在。

然后尝试了自动化 Load Base Split&＃xff0c;发现效果也不好。

最后回归 SQL 本身&＃xff0c;仔细分析了业务查询逻辑和索引使用情况&＃xff0c;重新调整索引后有了明显效果&＃xff0c;但由于这是一个业务上小于当前时间的范围查询&＃xff0c;某些 Region 的负载还是会高一些 &＃xff0c;再配合定期扫描 Region 流量超出阈值做切分的脚本&＃xff0c;热点问题得到完美解决。

3、TiDB自身问题

此外还碰到了 TiDB 产品本身的bug&＃xff0c;我们生产环境使用了v5.3.2版本&＃xff0c;在该版本下当 limit offset 值特别大的时候&＃xff0c;如果此时碰上 IndexHashJoin 会导致 Session 处于假死状态&＃xff0c;并且持续占用 TiDB 节点内存无法释放&＃xff0c;同时也无法kill。

早期因为这个问题出现过几次 TiDB 节点 OOM 的情况&＃xff0c;只能不定期重启 TiDB Server 解决。经过仔细分析排查后定位到这是产品bug&＃xff0c;可以通过 HashJoin 关联方式绕过&＃xff0c;最后用 SQL Binding 的形式临时处理掉了。不过业务上这样的 SQL 比较多&＃xff0c;目前依然存在这个问题&＃xff0c;计划通过版本升级的方式&＃xff08;v5.4.3&＃xff09;彻底解决。

整体来说&＃xff0c;此次 WMS 3.0系统迁移非常顺利&＃xff0c;各方面都能够满足预期&＃xff0c;我们也期待未来把更多的业务系统接入到 TiDB 中&＃xff0c;在更多场景中感受分布式数据库带来的魅力&＃xff0c;助力业务的高速增长。

我们致力于用数字技术重构企业价值&＃xff0c;助力企业实现数字化转型升级&＃xff01;

更多交流&＃xff0c;欢迎联系我们~